API Gateway de Frontend: Federación de GraphQL y Composición de Esquemas

En el mundo del desarrollo de aplicaciones web modernas, gestionar datos de múltiples fuentes puede ser un desafío significativo. A medida que las aplicaciones crecen en complejidad y adoptan arquitecturas de microservicios, la necesidad de una forma unificada y eficiente de acceder a los datos se vuelve primordial. Un API Gateway de Frontend actúa como un punto de entrada central para las aplicaciones cliente, agregando datos de varios servicios de backend y proporcionando una experiencia optimizada tanto para los desarrolladores como para los usuarios finales. Esta publicación de blog explora dos técnicas poderosas para construir un API Gateway de Frontend: la Federación de GraphQL y la Composición de Esquemas (Schema Stitching).

¿Qué es un API Gateway de Frontend?

Un API Gateway de Frontend es un patrón arquitectónico donde un servidor dedicado actúa como intermediario entre los clientes de frontend (por ejemplo, navegadores web, aplicaciones móviles) y múltiples servicios de backend. Simplifica la obtención de datos al:

• Agregar datos: Combinar datos de múltiples fuentes en una única respuesta.
• Transformar datos: Adaptar los formatos de datos para satisfacer las necesidades del frontend.
• Abstraer la complejidad: Ocultar las complejidades de los servicios de backend al cliente.
• Aplicar seguridad: Implementar políticas de autenticación y autorización.
• Optimizar el rendimiento: Almacenar en caché datos de acceso frecuente y reducir las solicitudes de red.

Esencialmente, implementa el patrón Backend para Frontend (BFF) a escala y capacita a los equipos de front-end para tomar más control de las API que consumen. En organizaciones más grandes, tener al front-end gestionando y curando sus propias API puede llevar a una entrega más rápida y una menor dependencia de los equipos de backend.

¿Por qué usar GraphQL para un API Gateway de Frontend?

GraphQL es un lenguaje de consulta para API y un tiempo de ejecución para satisfacer esas consultas con tus datos existentes. Ofrece varias ventajas sobre las API REST tradicionales, lo que lo hace muy adecuado para construir API Gateways de Frontend:

• Obtención de datos eficiente: Los clientes solicitan solo los datos que necesitan, reduciendo la sobrecarga de datos (over-fetching) y mejorando el rendimiento.
• Tipado fuerte: Los esquemas de GraphQL definen la estructura de los datos, lo que permite mejores herramientas y validación.
• Introspección: Los clientes pueden descubrir los datos y operaciones disponibles a través de la introspección del esquema.
• Capacidades en tiempo real: Las suscripciones de GraphQL permiten actualizaciones de datos en tiempo real.

Al aprovechar GraphQL, un API Gateway de Frontend puede proporcionar una interfaz flexible, eficiente y amigable para el desarrollador para acceder a datos de múltiples servicios de backend. Esto contrasta marcadamente con los enfoques tradicionales que utilizan múltiples endpoints REST, cada uno de los cuales necesita ser consultado individualmente y a menudo devuelve más datos de los necesarios.

Federación de GraphQL: Un Enfoque Distribuido

¿Qué es la Federación de GraphQL?

La Federación de GraphQL es una técnica poderosa para construir una API de GraphQL distribuida mediante la composición de múltiples servicios de GraphQL (llamados "subgrafos") en un esquema único y unificado. Cada subgrafo es responsable de un dominio o fuente de datos específico, y el gateway de federación orquesta las consultas a través de estos subgrafos.

El concepto central gira en torno a un supergrafo, un esquema de GraphQL único y unificado que representa toda la API. Este supergrafo se construye componiendo esquemas de GraphQL más pequeños, llamados subgrafos, cada uno representando un microservicio o fuente de datos específico. El gateway de federación es responsable de enrutar las consultas de GraphQL entrantes a los subgrafos apropiados y combinar los resultados en una única respuesta.

Cómo funciona la Federación de GraphQL

1. Definición de Subgrafos: Cada microservicio expone una API de GraphQL (un subgrafo) que define sus propios datos y operaciones. Estos esquemas incluyen directivas que le dicen al gateway de federación cómo resolver tipos y campos. Las directivas clave incluyen `@key`, `@external` y `@requires`.
2. Composición del Supergrafo: El gateway de federación (por ejemplo, Apollo Gateway) recupera los esquemas de cada subgrafo y los compone en un esquema único y unificado (el supergrafo). Este proceso implica resolver conflictos de tipos y campos y establecer relaciones entre tipos a través de diferentes subgrafos.
3. Planificación y Ejecución de Consultas: Cuando un cliente envía una consulta de GraphQL al gateway, este analiza la consulta y determina qué subgrafos deben ser consultados para satisfacer la solicitud. Luego distribuye la consulta a los subgrafos apropiados, recopila los resultados y los combina en una única respuesta, que se devuelve al cliente.

Ejemplo: Plataforma de E-commerce con Federación de GraphQL

Consideremos una plataforma de comercio electrónico con microservicios separados para productos, clientes y pedidos.

• Subgrafo de Productos: Gestiona la información de los productos (nombre, descripción, precio, etc.).
• Subgrafo de Clientes: Gestiona los datos de los clientes (nombre, dirección, correo electrónico, etc.).
• Subgrafo de Pedidos: Gestiona la información de los pedidos (ID de pedido, ID de cliente, ID de productos, importe total, etc.).

Cada subgrafo expone una API de GraphQL, y el gateway de federación compone estas API en un único supergrafo. Un cliente puede entonces consultar el supergrafo para recuperar información sobre productos, clientes y pedidos en una sola solicitud.

Por ejemplo, una consulta para recuperar el nombre de un cliente y su historial de pedidos podría verse así:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

El gateway de federación enrutaría esta consulta a los subgrafos de Clientes y Pedidos, recuperaría los datos necesarios y los combinaría en una única respuesta.

Beneficios de la Federación de GraphQL

• Acceso a datos simplificado: Los clientes interactúan con un único endpoint de GraphQL, independientemente de las fuentes de datos subyacentes.
• Rendimiento mejorado: La obtención de datos se optimiza al recuperar solo los datos necesarios de cada subgrafo.
• Mayor escalabilidad: Cada subgrafo se puede escalar de forma independiente, lo que permite una mejor utilización de los recursos.
• Desarrollo descentralizado: Los equipos pueden desarrollar e implementar subgrafos de forma independiente, promoviendo la agilidad y la innovación.
• Gobernanza del esquema: El gateway de federación garantiza la coherencia y compatibilidad del esquema entre los subgrafos.

Herramientas para la Federación de GraphQL

• Apollo Federation: Una popular implementación de código abierto de la Federación de GraphQL, que proporciona un gateway, un registro de esquemas y herramientas para construir y gestionar API de GraphQL federadas. Apollo Federation es conocida por su escalabilidad y robusto manejo de errores.
• GraphQL Hive: Esta herramienta ofrece registro y gobernanza de esquemas para servicios federados de GraphQL, proporcionando características como detección de cambios, análisis de uso y comprobaciones de esquemas. Mejora la visibilidad y el control sobre el supergrafo.

Composición de Esquemas (Schema Stitching): Un Enfoque Alternativo

¿Qué es la Composición de Esquemas (Schema Stitching)?

La Composición de Esquemas (Schema Stitching) es otra técnica para combinar múltiples esquemas de GraphQL en un esquema único y unificado. A diferencia de la Federación, la Composición de Esquemas generalmente implica un proceso más manual de definir cómo se conectan los tipos y campos de diferentes esquemas. Aunque la Federación se considera una solución más moderna y robusta, la Composición de Esquemas puede ser una opción viable para casos de uso más simples o al migrar desde API de GraphQL existentes.

Cómo funciona la Composición de Esquemas

1. Definición de Esquemas: Cada microservicio expone una API de GraphQL con su propio esquema.
2. Lógica de Composición: Una capa de composición (a menudo implementada usando librerías como GraphQL Tools) define cómo se conectan los tipos y campos de diferentes esquemas. Esto implica escribir funciones resolver que obtienen datos de los servicios subyacentes y los mapean al esquema unificado.
3. Esquema Unificado: La capa de composición combina los esquemas individuales en un esquema único y unificado que se expone al cliente.

Ejemplo: Componiendo Productos y Reseñas

Imagina dos servicios de GraphQL separados: uno para productos y otro para reseñas.

• Servicio de Productos: Proporciona información sobre productos (ID, nombre, descripción, precio).
• Servicio de Reseñas: Proporciona reseñas para productos (ID, ID de producto, calificación, comentario).

Usando la Composición de Esquemas, puedes crear un esquema unificado que permita a los clientes recuperar información de productos y reseñas en una sola consulta.

Definirías una función resolver en la capa de composición que obtiene las reseñas para un ID de producto dado del Servicio de Reseñas y las agrega al tipo Producto en el esquema unificado.

// Ejemplo (Conceptual): Lógica de composición usando GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Define tu esquema de productos
const reviewsSchema = ... // Define tu esquema de reseñas

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Obtener reseñas para el producto desde el Servicio de Reseñas
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

Este ejemplo demuestra el concepto central de componer esquemas. Observa la necesidad de resolvers personalizados para obtener el campo `reviews`. Esta sobrecarga adicional de codificar resolvers para cada relación puede hacer que el proceso de desarrollo sea más lento que usando Federación.

Beneficios de la Composición de Esquemas

• API Unificada: Los clientes acceden a un único endpoint de GraphQL, simplificando el acceso a los datos.
• Adopción incremental: La Composición de Esquemas se puede implementar de forma incremental, permitiéndote migrar gradualmente a una API unificada.
• Flexibilidad: La Composición de Esquemas proporciona más control sobre cómo se combinan los esquemas, permitiéndote personalizar la lógica de composición para satisfacer necesidades específicas.

Desventajas de la Composición de Esquemas

• Configuración manual: La Composición de Esquemas requiere la configuración manual de la lógica de composición, lo que puede ser complejo y llevar mucho tiempo.
• Sobrecarga de rendimiento: Las funciones resolver pueden introducir una sobrecarga de rendimiento, especialmente si implican transformaciones de datos complejas.
• Escalabilidad limitada: La Composición de Esquemas puede ser más difícil de escalar que la Federación, ya que la lógica de composición suele estar centralizada.
• Propiedad del esquema: Puede generar ambigüedad sobre la propiedad del esquema, particularmente si diferentes equipos gestionan los servicios compuestos.

Herramientas para la Composición de Esquemas

• GraphQL Tools: Una librería popular para construir y manipular esquemas de GraphQL, que incluye soporte para la Composición de Esquemas.
• GraphQL Mesh: GraphQL Mesh te permite usar el lenguaje de consulta GraphQL para acceder a datos de diversas fuentes como API REST, bases de datos y gRPC. Puede componer estas API en un esquema de GraphQL unificado.

Federación de GraphQL vs. Composición de Esquemas: Una Comparación

Tanto la Federación de GraphQL como la Composición de Esquemas ofrecen formas de combinar múltiples esquemas de GraphQL en una sola API, pero difieren en su enfoque y capacidades.

Característica	Federación de GraphQL	Composición de Esquemas
Enfoque	Composición distribuida y automatizada	Configuración centralizada y manual
Complejidad	Menor complejidad para mantener y escalar	Mayor complejidad debido a la lógica manual de los resolvers
Escalabilidad	Diseñada para sistemas distribuidos a gran escala	Menos escalable, típicamente usada para aplicaciones más pequeñas
Gobernanza del esquema	Gobernanza y validación de esquemas incorporadas	Requiere gestión y coordinación manual del esquema
Herramientas	Fuerte ecosistema de herramientas y librerías (ej. Apollo Federation)	Requiere más herramientas y configuración personalizadas
Casos de uso	Arquitecturas de microservicios, API a gran escala, desarrollo descentralizado	Aplicaciones más pequeñas, migración incremental, requisitos de personalización específicos

Cuándo usar la Federación de GraphQL: Elige Federación cuando tengas una arquitectura de microservicios compleja, necesites escalar tu API y quieras capacitar a equipos independientes para que gestionen sus propios subgrafos. También simplifica la gestión y gobernanza del esquema.

Cuándo usar la Composición de Esquemas: Considera la Composición de Esquemas cuando tengas una API más simple, necesites más control sobre la lógica de composición o estés migrando desde API de GraphQL existentes. Sin embargo, ten en cuenta las posibles complejidades y limitaciones de escalabilidad.

Implementación de Autenticación y Autorización

Independientemente de si eliges la Federación de GraphQL o la Composición de Esquemas, implementar la autenticación y autorización es crucial para asegurar tu API Gateway de Frontend. Hay varios enfoques que puedes tomar:

• Autenticación a nivel de Gateway: El API Gateway maneja la autenticación y autorización antes de enrutar las solicitudes a los servicios de backend. Este enfoque centraliza la lógica de seguridad y simplifica los servicios de backend. Los métodos comunes incluyen la validación de JWT (JSON Web Token) y OAuth 2.0.
• Autenticación a nivel de Servicio: Cada servicio de backend maneja su propia autenticación y autorización. Este enfoque proporciona un control más granular sobre la seguridad pero puede ser más complejo de gestionar.
• Enfoque Híbrido: Una combinación de autenticación a nivel de gateway y a nivel de servicio. El gateway maneja la autenticación inicial, y los servicios de backend realizan comprobaciones de autorización más granulares.

Ejemplo: Autenticación JWT con Apollo Federation

Con Apollo Federation, puedes configurar el gateway para validar tokens JWT incluidos en las cabeceras de la solicitud. El gateway puede entonces pasar la información del usuario extraída del token a los subgrafos, los cuales pueden usar esta información para la autorización.

// Ejemplo (Conceptual): Configuración de Apollo Gateway con validación JWT
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... tus configuraciones de subgrafos
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Nombre del subgrafo
      url,   // URL del subgrafo
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Obtener el usuario del contexto
    const user = context.user;

    // Añadir el ID del usuario a las cabeceras de la solicitud
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

En este ejemplo, se crea un servicio personalizado para modificar las solicitudes salientes e incluir el ID de usuario derivado del JWT. Los servicios descendentes pueden entonces usar este ID para las comprobaciones de autorización.

Estrategias de Caché para la Optimización del Rendimiento

El almacenamiento en caché es esencial para mejorar el rendimiento de un API Gateway de Frontend. Al almacenar en caché los datos de acceso frecuente, puedes reducir la carga en los servicios de backend y mejorar los tiempos de respuesta para los clientes. Aquí hay algunas estrategias de caché:

• Caché HTTP: Aprovecha los mecanismos de caché HTTP (por ejemplo, cabeceras `Cache-Control`) para almacenar respuestas en el navegador y en proxies intermedios.
• Caché en Memoria: Usa cachés en memoria (por ejemplo, Redis, Memcached) para almacenar datos de acceso frecuente en el gateway.
• Caché de CDN: Utiliza Redes de Distribución de Contenido (CDN) para almacenar activos estáticos y respuestas de API más cerca del cliente.
• Caché de Consultas GraphQL: Almacena en caché los resultados de las consultas de GraphQL basándose en su cadena de consulta y variables. Esto puede ser particularmente efectivo para consultas ejecutadas con frecuencia. Apollo Server ofrece soporte incorporado para el almacenamiento en caché de consultas.

Al implementar el almacenamiento en caché, considera estrategias de invalidación de caché para asegurar que los clientes reciban datos actualizados. Las estrategias comunes incluyen:

• Expiración basada en tiempo: Establece un tiempo de expiración fijo para los datos en caché.
• Invalidación basada en eventos: Invalida la caché cuando los datos cambian en los servicios de backend. Esto se puede lograr usando webhooks o colas de mensajes.

Monitorización y Observabilidad

La monitorización y la observabilidad son críticas para asegurar la salud y el rendimiento de tu API Gateway de Frontend. Implementa una monitorización exhaustiva para rastrear métricas clave como:

• Latencia de solicitud: El tiempo que toma procesar una solicitud.
• Tasas de error: El porcentaje de solicitudes que resultan en errores.
• Rendimiento (Throughput): El número de solicitudes procesadas por unidad de tiempo.
• Utilización de recursos: Uso de CPU, memoria y red del gateway y los servicios de backend.

Usa el rastreo (tracing) para seguir las solicitudes a medida que fluyen por el sistema, identificando cuellos de botella y problemas de rendimiento. El registro (logging) proporciona información valiosa sobre el comportamiento del gateway y los servicios de backend.

Las herramientas para monitorización y observabilidad incluyen:

• Prometheus: Un sistema de monitorización y alertas de código abierto.
• Grafana: Una herramienta de visualización y monitorización de datos.
• Jaeger: Un sistema de rastreo distribuido de código abierto.
• Datadog: Una plataforma de monitorización y seguridad para aplicaciones en la nube.
• New Relic: Una plataforma de inteligencia digital para monitorizar y mejorar el rendimiento del software.

Al implementar una monitorización y observabilidad robustas, puedes identificar y resolver problemas de manera proactiva, asegurando la fiabilidad y el rendimiento de tu API Gateway de Frontend.

Conclusión

Un API Gateway de Frontend construido con Federación de GraphQL o Composición de Esquemas puede simplificar significativamente el acceso a los datos, mejorar el rendimiento y potenciar la experiencia del desarrollador en las aplicaciones web modernas. La Federación de GraphQL proporciona una solución potente y escalable para componer API de GraphQL distribuidas, mientras que la Composición de Esquemas ofrece un enfoque más flexible para combinar esquemas existentes. Al considerar cuidadosamente los requisitos específicos de tu aplicación y las compensaciones entre estas técnicas, puedes elegir el mejor enfoque para construir un API Gateway de Frontend robusto y eficiente.

Recuerda implementar una autenticación y autorización adecuadas, estrategias de caché, y monitorización y observabilidad para garantizar la seguridad, el rendimiento y la fiabilidad de tu gateway. Al adoptar estas mejores prácticas, puedes desbloquear todo el potencial de GraphQL y construir aplicaciones web modernas que ofrezcan experiencias de usuario excepcionales.